The present invention relates to a data management system for a database where the database responds to data manipulation requests initiated by several users. Such databases are particularly useful in enterprise management systems, computer networks that facilitate ordinary business tasks such as issuing purchase orders, preparing quotes, scheduling product shipments and the like. In such systems, databases store various data records, called “business objects” which store data regarding these business tasks and also other business records such as information regarding customers, vendors, suppliers and distribution partners (collectively, “business partners”). Enterprise management systems may provide support to several operators, which may issue concurrent and possibly conflicting requests that address the same data record. If multiple requests to a database (called “transactions” herein) are performed without regard to each other, data consistency errors can arise.
At present, methods for transaction management is heavily dependent on a system's underlying structure and database format. For example, FIG. 1 shows a flowchart of a simple method for transaction management that may be performed in the prior art. As shown, a user1 starts a connection with a database at 101, which locks an object he is interested in at 102. If the user1 cannot successfully lock the objects he is interested in, the process returns to 101. If the lock is successfully applied to the object, no other system user (e.g., user2) can operator on the locked object. The user1 starts the transaction at 103, and performs database operations like “check,” “select,” “insert,” “update/delete” at 104, 105, 106 and 107. If an error occurs during a database operation, the transaction rollback is done at 108, which reverts the state of the locked object to the state that it had prior to the lock. Thereafter, the process proceeds to 110. If no error occurred, the user1 may commit results of the transaction to storage, making the transaction permanent at 109, and the process proceeds to 110. At 110, the objects are unlocked and the connection is released. Other users, e.g., a user2, can perform transactions only if he can lock the objects he is interested in, as shown at 111, 112, 113, 114, 115, 116, 117, 118, 119, and 120. In such a system, if two users issue concurrent requests to a common object, only one user can lock the object. The other user's operation is delayed while the first user's lock is active.
The available transaction management requires direct support for the transactions from the database or platform. However, operations supported by databases or platforms from different vendors vary. For example, some databases may not support explicit start of a transaction, and some only support implicit database commit.
The available method requires considerable coding to handle concurrency. In a multi-user environment, there are two common models for updating data in a database: optimistic concurrency, and pessimistic concurrency. Pessimistic concurrency requires considerable amount of codes to lock and unlock data objects. Some applications use timestamp to implement optimistic concurrency, but also need considerable coding. Further, it is not possible to support both optimistic concurrency and pessimistic concurrency.
Database Control Language (DCL) like Grant, Check, Constraint, Primary Key, and Foreign Key varies in syntax in databases from different vendors. Some databases or platforms may not support Primary Key and Foreign Key check. Because of the insufficient data validation, programmers have to write considerable lines of codes to check the data before updating the database.
Thus, it would be desirable to provide a generic data manipulation method which provides effective concurrency and data validation check but is independent of the type of database and does not require excessive coding. It would also be desirable to provide a generic data manipulation method which has enhanced exception handling, performance tuning, and table entry authority check.